Method and System for Transparently and Securely Interconnecting a WLAN Radio Access Network Into a GPRS/GSM Core Network

ABSTRACT

A method and system are provided for integrating a WLAN radio access network into a GSM/GPRS core network wherein gateways are added that transparently transport services between the two networks. A further aspect of the invention is secure authentication The system has two network elements: a Radio Link Manager (RLM) and a Radio Access Controller (RAC), and a software application, a Multi-Link Client (MLC) to control the functionality of the integration and the authentication. The MLC resides on a user device. The RAC provides protocol stacks and interworking functions to allow the MLC to talk to a Home Location Register (HLR). The RLM and MLC set up a “tunnel” employing, for example, PPP over Ethernet (PPPOE), and all of the data packets received on this tunnel are forwarded by the RLM to the Gateway GPRS Support Node (GGSN over a further tunnel using the GPRS Tunneling Protocol (GTP).

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority from U.S. non-provisional applicationSer. No. 10/176,198, titled “Method and System for Transparently andSecurely Interconnecting a WLAN Radio Access Network Into a GPRS/GSMCore Network” filed on Jun. 19, 2002, which is hereby incorporated byreference.

BACKGROUND OF THE INVENTION

The present invention relates to interworking of wireless local areanetworks (WLANs) with cellular networks in order to provide connectivityfor packet data services for cellular networks, particularly GSM-basedcellular networks. The invention also relates to techniques to overlaysecurity and privacy onto network elements that do not provide such.[05] There is a need for a solution that provides high-speed wirelessdata networking for a customer of GSM services. It is desirable to do sowithout modifying the core network elements of any GSM service andparticularly those that have already deployed support for GSM PacketRadio Services (GPRS). By leaving the core network intact, it isbelieved that the cost of adding high-speed wireless data networking toa GSM network can be reduced. [061 Add-on high-speed wireless servicesmust be provided as efficiently and inexpesively as possible in order tocompete with integrated services. A first step towards achieving thisgoal would be to use standard-based networking elements, such as, butnot limited to, WLAN devices using the IEEE 802.11b networkingprotocols. However, these networking protocols are relativelyrudimentary and provide specifications merely for the first two layersof a typical Open Systems Interconnection (OSI) defined seven-layerstack: The physical layer and the Media Access and Control (MAC) layer.

FIG. 1 illustrates the conventional OSI model applied to an IEEE 802.11and Internet Engineering Task Force (IETF) stack for a wireless LAN. Inthe past, in order to interconnect this stack to the GSM stack at thetop or application level, application gateways had to be provided. Thisinterface methodology for interoperation with WLAN systems is difficultfor GSM/GPRS services to provide because GSM/GPRS services are based oncompletely different standards and provide many features not found inthe IETF and IEEE 802.11b stacks. For instance, IETF systems do not yetprovide the functionality needed to support GSM services. IETF protocolsdo not provide a secure authentication system for interoperation withthe GSM authentication system, accounting functions are in differentformats, allocation of customer IP addresses is handled at a differentlayer of the networking stacks, roaming features are incompatible, andthe IETF does not specify a micro-mobility handover protocol such asthat which is detailed in GSM. In fact, when interoperating IETF and GSMsystems, the typical GSM service would simply deploy two separatesystems and consolidate billing afterwards. This solution isundesirable, because it is difficult for the GSM operator to manage twodisparate customer databases, provide two different servers and clientsfor each additional service they wish to deploy, and manage two entirelydifferent network systems with different network management systems.

Therefore, there is a need for a set of interworking network elementsthat either translates services or provides additional services over theWLAN radio access network. In addition, there is a need to provide anarchitecture for interworking elements in a manner that requires littleor no modifications to the GSM system.

There have been various efforts to address and improve the deployment ofhigh-speed data services using WLAN. One such method provided by severalvendors uses interworking elements between the WLAN and typical InternetService Provider (ISP) core networks. In this method, WLAN Access Points(APs) providing physical layer and MAC layer functionality are connectedto modified Internet Protocol (IP) routers. These routers typicallysupport routing layer IETF standards such as, but not limited to,Routing Internet Protocol (RIP), and they typically use IETFstandards-based authentication and accounting systems that incorporateprotocols such as, but not limited to, Remote Access Dial In UserService (RADIUS).

Realizing these difficulties, several vendors (Cisco Systems of SantaClara, Calif., Service Factory of Stockholm, Sweden, and LucentTechnologies) have tried to provide interworking elements in order tohandle each of the above-described faults and many additional problems.For instance, several vendors have added features to the Access Pointsin order to add higher networking layer functionality such asauthentication and security. This method is not ideal, because there isno IETF standard covering this area at this time. As such, usingcustomized Access Points requires a GSM/GPRS service to deploy onlythose APs that are able to support these proprietary protocols. Inaddition, some vendors that have built additional features andfinctionalities into their WLAN client hardware have limited the type ofnetwork interface cards that customers can use to connect into thenetwork and thus causes additional incompatibilities, which isparticularly undesirable if the customer does not have the option ofusing a customized interface.

Realizing this difficulty, some vendors (Nokia of Finland, CiscoSystems, IP Unplugged of Sweden, PC Tel of Santa Clara, Calif.) haveconcentrated on providing back-end solutions to the billing andprovisioning systems by adding so-called Charging Gateways. Thesegateways translate the billing records coming out of the standard IETFsystems into the proprietary systems used by the GSM/GPRS services.Since there are no standards for billing systems, it is difficult toensure transparency for new and future modifications to existingservices.

Other vendors (Transat of Houston, Tex. and Interwave of Menlo Park,Calif.), recognizing these difficulties, have built stand-alone GSM/GPRSsystems that communicate with customers using WLAN facilities, therebyreplacing all of the core network functions and capabilities that existin the GSMIGPRS core network. This system is also not desirable becausethe GSM/GPRS service must nonetheless continue to operate two distinctnetworks with different management and configuration commands andadditional hardware and software, even though it provides the GSMoperator with a more familiar replacement network.

Therefore, there is a need for an interworking system between the WLANradio access network and the GSM/GPRS core network that enables the GSMservice to transparently connect users over this new radio accessnetwork, while providing to GSM customers all of the services that thecustomers have come to expect. In addition, it would be useful if thisinterworking system could be extended in order to support other radioaccess networks such as 3G, 802.11 a, or High Performance Radio LocalArea Networks (HIPERLAN) in the future with little or no additionalmodification. Such a system would eschew any requirements for the WLANelements to be modified and would interconnect the two networks at thelowest networking layers possible, as well as provide additionalfeatures at the lowest networking layers possible in order to make bestpossible use of the GSM standards already deployed. These featuresshould be provided via separate networking elements. In this way,functionality can be added to other radio access networks with littleadditional work.

SUMMARY OF THE INVENTION

According to the present invention, a method and system are provided forintegrating a WLAN radio access network into a GSM/GPRS core networkwherein gateways are added that function to transparently transportservices between two dissimilar types of networks such as WLAN and GSM.A further aspect of the invention is secure authentication. The systemaccording to the invention has two network elements, a Radio LinkManager (RLM) and a Radio Access Controller (RAC), and a softwareapplication, a Multi-Link Client (MLC) to control the functionality ofthe integration. The MLC resides on a user device such as, but notlimited to, a Laptop, PDA, or cellular telephone. The WLAN Radio AccessNetwork (RAN) comprises a client radio, which is typically either builtinto a client computing device or installed via a PCMCIA card, and anAccess Point (AP), which provides translation of the wireless signalsfrom the client radio onto a wired networking protocol. According to themethod of the invention, in order to connect this RAN to the GSM/GPRScore network, the Radio Link Manager is located between the AP and theCore Network (CN) and provides an endpoint for a secure connection fromthe MLC software on the client computing device. The RLM forwardsauthentication messages from the MLC to the RAC. The RAC providesprotocol stacks and interworking functions in order to allow the MLC totalk to a Home Location Register (HLR), which is a standard networkelement in the GSM core network that handles authentication. After thecustomer is authenticated, the RLM and the MLC set up a “tunnel”employing Point-to-Point Protocol (PPP) Over Ethernet (PPPOE), and allof the data packets received on this tunnel are forwarded by the RLM tothe Gateway GPRS Support Node (GGSN), a standard network element in theGSM/GPRS network that provides interconnection to the Internet or otherpacket data network. In order to do this forwarding, the RLM sets up atunnel using GPRS Tunneling Protocol (GTP) from the RLM to the GGSN.Alternatively, a datalink tunnel could be from the RLM to an Internetgateway that has tunneling capabilities and address assignmentcapabilities as part of a global packet data network. Examples areGeneric Routing Encapsulation (GRE) protocol, IP in IP tunneling, Layer2 Transport Protocol (L2TP), Mobile IP, and Metricom's RicochetTunneling Protocol related to disparate mesh networks. There may beother examples, which are equivalent but not foreseeable at the presenttime.

The two networks can interoperate seamlessly, allowing a customer tocontinue receiving all of the networking services currently availableunder GSM regardless of the radio access network that is utilized at agiven time.

The invention will be better understood by reference to the followingdetailed description in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts the network stack for the IEEE WLAN specifications andthe network stack specified by the IETF for the Internet protocol andcompares it to the OSI model of networking. (Prior Art)

FIG. 2 depicts an ipRAN for WLAN architecture according to theinvention.

FIG. 3 depicts a GSM network as upgraded to support GPRS and WLANaccording to the present invention.

FIG. 4 depicts user equipment necessary in a specific embodiment of thepresent invention.

FIG. 5 depicts messages passed between the various elements of the ipRANfor WLAN and the GSMIGPRS core network for authentication of a customer.

FIG. 6 depicts a preferred embodiment of the packet formats in the RRprotocol between a Radio Link Manager and a Radio Access Controller.

DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION

The present invention is a method and apparatus for connecting aWireless Local Area Network Radio Access Network (WLAN RAN) to a GSMcellular telephone system that is upgraded with GPRS capabilities. Inorder to provide GPRS capabilities, the GSM network must add a ServingGPRS Support Node (SGSN) 304 as well as a Gateway GPRS Support Node(GGSN) 326 as shown in FIG. 3.

In order to understand the improvement represented by the presentinvention, it is helpful to first identify those elements that are knownin the art. The standard network elements in GSM/GPRS are shown on theleft side of FIG. 3. Before a GPRS upgrade, the cellular system supportsvoice calls that are routed from a Base Station Controller (BSC) 303 toa Mobile Switching Center (MSC) 327 and thence onto the Public SwitchedTelephone Network (PSTN) 329. For GPRS, which supports data, the dataconnections are routed from the BSC 303 to the SGSN 304, then to a GGSN326 and thence to a Packet Data Network (PDN) 306. The path of thesignals over the air for GPRS is physically the same as for voice calls.However, GPRS uses different protocols on all of the connections. Inconventional operation, a user device 301 supports a GPRS radio air link313 and sends packets to a Basestation Transmitter Server (BTS) 302. TheBTS 302 forwards the packets over a direct connection 14 to one of theBSCs 303 using frame relay or other protocol. The BTS 302 and BSC 303also handle voice calls and all of the additional complexity requiredfor such traffic. Data packets, however, are always routed through thedirect connection 315 to a SGSN 304. The SGSN 304 then routes the datapackets through the network connection 317 to the GGSN 326, typicallyusing GTP over internet protocols. The SGSN 304 also regulates andrecords the Quality of Service (QOS) of the data packet connection andthe number of packets and duration of connections as defined in GPRSprotocols. The SGSN 304 transmits this information over a directconnection 316 to a Charging Gateway Function 305 in order to allowusers to be billed according to the Quality of Service (QOS). The SGSN304 also relays the authentication protocol from a Subscriber IdentityModule (SIM) 417 (FIG. 4) inside the User Equipment (UE) 301 to a HomeLocation Register (HLR) 311 over a Signaling System 7 (SS7)-type network324 using Mobile Application Part (MAP) protocol. The GGSN 326 routesthe data packets over the network 319 typically using the Internetprotocol to a Public Data Network (PDN) 306, typically the Internet.

According to the invention, and referring now to the right side of FIG.3, the data packet sent from the UE 309 supporting WLAN is eventuallysent to the PDN 306. The data packet is sent over a WLAN air link 322from the UE 309 to a WLAN Access Point (AP) 308. The AP 308 forwards thepacket to a Radio Link Manager (RLM) 307 over the bridged network 321,typically Ethernet, but possibly over DSL, fiber, or other suitablephysical medium. The RLM 307 forwards the data packet over network 320,typically using GTP over the Internet Protocol (GTP/IP), to the GGSN326. The GGSN 326 then forwards the data packets to the packet datanetwork 306 over the network connection 319, typically using theInternet Protocol. In the invention herein described, the networkelements for providing interworking functions to WLAN split the datapackets and control packets of the protocols from the UE 301 at the RLM307 to the different network elements only as needed. The authenticationpackets are routed to the Radio Access Controller (RAC) 310 over thenetwork connection 325, typically using the RLM to RAC (RR) protocolover the Internet protocol. The RAC 310 forwards the authenticationpackets to the HLR 311 over the SS7 network 323 using MAP. Theauthentication protocol operates from the UE supporting WLAN 309 usingits SIM card via the Multi-Link Client software. In GPRS or in WLAN, theGGSN 326 sends charging data over the direct connection 318 to theCharging Gateway Function 305. The Charging Gateway Function records thetotal connection time and quantity of data packets sent by the UE 309 or301 to the PDN 306.

In the case of WLAN, there is no QOS on the air link 322, unlike in thecase of GPRS, where the BTS 302 can provide QOS over the air link 313.In GPRS, this information is recorded and sent to the Charging GatewayFunction 305 via the direct connection 316 from the SGSN 304. In theMiLAN case, this information is not needed and thus can be ignored.

To the core network elements of GSM, which has the GGSN 326 and theCharging Gateway Function 305, the WLAN connection now emulates a GPRSconnection. The RLM 307 emulates the SGSN 304 for the connection to theGGSN 326. The RAC 310 emulates the SGSN 304 for the connection to theHLR 311, while the SGSN 304 connection to the Charging Gateway Functionis not needed for MiLAN, because there are no QOS capabilities in theWLAN air link. In this manner, provisioning of the WLAN service for aparticular user can be entered into the HLR 311 in the same manner thatthe user's GPRS service is entered. Billing can also be done at theCharging Gateway Function 305 in an exactly analogous manner. Thus, withthe internetworking functions provided by the RLM 307 and the RAC 310,the WLAN RAN can be connected to a GSM/GPRS core network with nomodifications to the core network or to any procedures that are used tomanage and provision services on said core network.

Referring to FIG. 2, a specific embodiment of the hardware elements thatimplement the invention is shown. Other embodiments may be obvious toone skilled in the art of networking and are not precluded by thedescription herein. The interworking elements between the WLAN and thecore GSM/GPRS network include an MLC (Multi-Link Client) which issoftware on the client hardware 201, an RLM (Radio Link Manager) 206which is the routing and control point for authentication and data flow,and the RAC (Radio Access Controller) 207, which is the interworkingelement for authentication and provisioning.

The user equipment UE is a computing device with a WLAN radio, such as,but not limited to, a Personal Data Assistant (PDA) 202, a cellulartelephone 203 or a laptop 204. An air link 218 used by the WLAN radioembedded in the computing devices 202, 203, or 204 may be based on theIEEE 802.11b specification or may be based on any other air link thatcan be translated onto a bridged network via the Access Point (AP) 204.Examples of other air link protocols and radios that may be used are theIEEE 802.11a or 802.11g specifications, the HIPERLAN specification, orsome other air link yet to be determined. In the preferred embodiment,the only requirement is that the AP 204 supports the IEEE 802.1Dbridging protocol specification. This protocol can be run using thephysical layer of Ethernet on the network 214 through a bridge or hub205 that forwards packets over the network 215 to the RLM 206. Thenetwork 215 can also use Ethernet, but the bridge or hub 205 may bereplaced with a DSL (Digital Subscriber Line) modem 219 and a remoteDSLAM (Digital Subscriber Line Access Manager) 221 connected by atwisted pair copper wire 220, as long as the packet appears on network215 just as it did on network 214 and as long as the IEEE 802.1Dbridging protocol specification is met between both physical networkconnections 214 and 215, in order for both to appear as one bridgednetwork to the RLMs 206. Other methods of connecting the APs 204 to theRLMs 206 should be evident to one skilled in the art of networking. Itis also evident to one skilled in the art of networking that the numberof APs 204 on networks 214 is not fixed, as many as needed may be usedfor redundancy and capacity.

The UE 201, 202, or 203 is shown in detail in FIG. 4. The UE 201 has adevice case 414 containing a CPU (Central Processing Unit) 402 thatcommunicates over a connection or bus 410 with non-volatile storage 403where various programs in the form of software instructions control theseveral devices 405, 406, 404, and 417, and perform their functions inthe UE by being interpreted by the CPU instruction-by-instruction. TheMulti-Link Client software is stored in the UE non-volatile storage 403as well. When the UE is powered on, the CPU 402 may copy the programs toRandom Access Memory 401 over a connection or bus 409, or may run theprograms directly from non-volatile storage 403. The user equipmenttypically has, but is not required to have, an output device 404, suchas a screen or a speaker that communicates over connection 412 to theCPU 402. This output device 404 can be controlled by the programsresident in non-volatile memory 403 or random access memory 401. Thedevice typically has, but is not required to have, an input device 405such as a keyboard, a mouse, or a microphone that communicates to theCPU 402 over connection 413. This input device 405 can be controlled bythe programs resident in non-volatile memory 403 or random access memory401. The UE device must have a WLAN radio 406 or equivalent that isconnected to the CPU 402 over a connection or bus 411 and connected toan antenna 407 over connection 408, typically but not necessarilyoutside the device box 414. In the preferred embodiment the device has aSIM reader 416 connected to the CPU 402 via connection 415 that canaccept a SIM card 417 and send and receive information from the SIM card417.

In a specific embodiment, this SIM Card information is sent to the CPU402 over connection or bus 415. The SIM Reader 416 may be embedded inthe device case 414, or may be external to the device case 414.

An appropriate method is used to invoke and run the software programcalled the MLC (Multi-Link Client), on user equipment 201, 202, or 203such as, but not limited to, the user of the equipment clicking on anicon on a screen (output device 404) using a mouse (input device 405),or in an alternative embodiment, a program pre-installed on the userequipment may recognize a signal from the WLAN radio 406 sent over theconnection 411 to the CPU 402 that alerts the MLC software to the factthat the WLAN radio 406 can attach itself to an AP 204.

In an alternative embodiment, a button (input device 405) may be pressedor some other method may be used as would be evident to one skilled inthe art of computer design and programming. The MLC, once notified thatthe data connection should be started, now attempts to authenticateitself to the HLR 217, which is part of the core GSM network. In thepreferred embodiment of the invention, the networks 214 and 215 shouldbe bridged Ethernet networks by a bridge or hub 205 as the Multi-LinkClient software uses Point to Point Protocol Over Ethernet (PPPOE) toset up a tunnel from the UE 201, 202 or 203 to an RLM 206. If anothermedium were to be used in networks 214 and 215 a different protocolcould be used to encapsulate the data packets sent over the air link 218that included the same required functionality: the ability to locate anRLM 206 that provides a tunnel server that can terminate a tunneloriginated in the MLC and the ability to send the packets over thetunnel through an AP 204. An example of another protocol method thatwould work to tunnel packets from the UE 201, 202, or 203 to the RLM 206is the Layer 2 Transport Protocol (L2TP). Still other examples areGeneric Routing Encapsulation (GRE) protocol, IP in IP tunneling, MobileIP, and Metricom's Ricochet Tunneling Protocol related to disparate meshnetworks. There may be other examples that are equivalent but notforeseeable at the present time.

In this embodiment, the MLC on the UE 201, 202, or 203 acts as an L2TPAccess Client and the network 214 and 215 is a routable network thatuses the Internet protocol. In this embodiment a set of routers replacethe bridge or hub 205 and functions to transport packets between the AP204 and the RLM 206. The RLM acts as an L2TP Network Server. The MLC isconfigured with the IP address of the RLM 206. In an alternativeembodiment, the MLC uses a standard Domain Name Service (DNS) Query tofind the RLM 206. This query provides the required functionality; itfinds the RLM 206 and allows for the tunneling of packets from the UE201, 202, or 203 to the RLM 206. Other methods used to tunnel packetsfrom the UE 201, 202, 203 to the RLM 206 will be evident to one skilledin the art of networking. The architecture does not limit the user toonly one or two RLMs 206 per network, but allows for any number of RLMs206 as needed for redundancy and capacity.

In a specific embodiment using IEEE 802.11 protocols, the AP 204 acts asa bridge, forwarding all data packets on the airlink 218 onto thebridged network 214 and forwarding all data packets from the bridgednetwork 214 to the correct UE 201, 202, or 203. The WLAN radio 406 inthe user equipment 201, 202, or 203 sends packets over the connection408 to the antennae 407 over the air link 218 which are received by theAP 204. The WLAN radio 406 uses IEEE 802.11 protocol in order to attachto one of the APs 204. Once the WLAN radio 406 is attached to an AP 204,it notifies the CPU 402 over the connection 413 and informs the devicedriver software resident in the non-volatile memory 403 or Random AccessMemory (RAM) 401. The device driver software uses standard signalingthrough the CPU 402 and bus 409 or 410 to notify the MLC software of theattachment event. The MLC then sends out a PPPOE Active DiscoveryInitiation (PADI) packet to the device driver that causes the WLAN radio406 to send it to the AP 204. The AP 204 will forward the PADI packet tothe network 214. Because this packet is addressed to the broadcastEthernet address on a bridged network, the packet will be replicatedonto networks 215, 214 and air links 218.

All of the RLMs 206 desirous of accepting a connection will respond tothe PADI packet with a unicast PPPOE Active Discover Offer (PADO)response packet addressed to the UE 201, 202, or 203. The PADO packet isreceived by the UE 201, 202, or 203 and forwarded to the MLC. The MLChas registered with the device driver of the WLAN Radio 406 to receivecopies of all of these types of packets. The PADO packets contain theIEEE MAC address of the RLMs 206. In this manner, the MLC can discoverthe address of the RLMs 206. The MLC now uses this address over thebridged networks 214 and 215 and air link 218 in order to set up a PPPOEtunnel between itself and its chosen RLM 206. The MLC uses PPPencapsulated in the PPPOE protocol in order to negotiate a PPPconnection with the RLM 206 using the source address of the PADO packet.

According to the invention, the MLC and the RLM 206 use an extensibleauthentication protocol, such as PPP or 802.1X, to pass the informationrequired to authenticate the SIM card 417 to the HLR 208, as well asauthenticate the RLM 206 to the MLC. Once the authentication iscomplete, information in the form of unique keys are provided by the HLR208 to the RLM 206 and by the SIM card 417 to the MLC to enable them toset up a secure connection between the two devices. Every packet isencrypted with the unique key known only to the RLM 206 and the MLC. TheMLC then acts as a firewall for the UE 201, 202, or 203 and drops allpackets except those correctly encrypted with the unique key. The RLM206 also acts as a firewall and drops all packets from network 215except those correctly encrypted with the unique keys from UE 201, 202,or 203. This prevents the UE 201, 202, or 203 from being able to addressan AP 204, another piece of user equipment 201, 202, or 203, the bridge205, or any other core network elements of the GSM system except throughthe RLM 206 which encapsulates and forwards the packets through the corenetwork to the GGSN 212 which only forwards the packets to the PDN 210the Internet, thus also protecting all of the core network elements fromany attacks from the UE 202, or 203. In addition, since the MLC dropsall packets not coming from the PPPOE tunnel of the RLM 206, there is nomethod for any other UE 201, 202, or 203, or any device, such as a hubor bridge 205 to inject packets that will be received by the UE, thussecuring it from any attacks of any devices connected to the corenetwork connection 212 or bridged network 214 and 215 or the air link218, providing secure public packet forwarding for the UE 201, 202, or203 and freeing the customer from worries of attack or abuse of the UE201, 201,or 203.

Referring to the packet flow diagram of FIG. 5, messages are passedbetween the various network elements in the WLAN RAN and the coreGSM/GPRS network for authentication of the customer's SIM card on the UE520 to the HLR 523. These messages authorize that the customer can useWLAN and start billing and include the set-up messages used to createend-to-end tunnels from the UE 520 to the RLM 521 and from the RLM 521to the GGSN 524, where data traffic is received and transmitted. Asdescribed above, the UE 520 finds the RLM 521 using PPPOE discoverypackets and encapsulates PPP packets in this protocol in order totransport them between the UE 520 and the RLM 521. FIG. 5 shows packetcommunication between the separate network elements: the UE 520, the RLM521, the RAC 522, the HLR 523, and the GGSN 524. Time increases from topto bottom. A separate number labels each packet or message with anarrowed line from the network element originating the packet and endingwith the network element receiving the packet.

FIG. 5 also shows ordering of the packets. Packets that are sent earlierin time are closer to the top of the diagram. FIG. 5 also shows thenames of selected protocols used between the UE 520 and the RLM 521, forinformational purposes only. In a specific embodiment, the devices usePPP to send packets back and forth and to negotiate authentication andother network configuration needed to make the UE 520 a fullyparticipating network element in the packet data network attached to theGGSN 524.

Between the UE 520 and the RLM 521 several sub-protocols of PPP may beused. These protocols include the Link Control Protocol (LCP), ChallengeAuthentication Protocol (CHAP), and IP Control Protocol (IPCP). Otherprotocols such as 802.1X may be used also. The packets or messages ineach protocol are grouped together for informational purposes, withlabels going down the left side of the diagram.

In a specific embodiment, the MLC on the UE 520 uses PPP to negotiatethe LCP configuration option type 0×20, with length 18 containing theInternational Mobile Subscriber Identifier (IMSI) and the LCPconfiguration option type 0×21 with a length of 18 bytes for the nonce,a pseudo-random number 16 bytes long that varies in each instance asunpredictably as possible, by sending the PPP LCP configuration optionpacket 501 to the RLM 521.

Another method of providing this information is to use vendor-specificLCP configuration methods and fields. The RLM 521 receives the LCPoptions and remembers the nonce (a random number used for challenge) forlater use. It then forwards the IMSI to the RAC 522 in the AttachRequest packet 502 of the RAC to RLM (RR) protocol as described in Table2. The RR protocol, as depicted in FIG. 6 and Table 1 in a specificembodiment, has an 8 bit version number, followed by an 8 bit messagenumber, followed by a 16 bit length, in bytes of the message payload tofollow, followed by the 32 bit identifier of the UE 520 as assigned bythe RLM 521 and which consists of 20 bits of RLM 521 uniqueidentification and 12 bits of unique identification for the UE 520assigned by the RLM 521, followed by the message payload itself. TABLE 1Message ID Attach Request 0x01 Auth Reject 0x02 Attach Accept 0x04Attach Complete 0x03 Authentication Request Ox12 Authentication ResponseOx13

The message number in the RR protocol for each of the messages betweenthe EAC and the RLM is listed in Table 1. The payloads of the AttachRequest packet 502 for the RR protocol between the RAC and the RLM aredescribed in Table 2. TABLE 2 Field name Size in bytes ValuesDescription Auth Type 1 Ox1 Designating IMSI IMSI_Len 1 0x07 to Ox1OLength of IMSI in bytes IMSI IMSI_Len IMSI Unique identifier for mobilesubscriber Old_RAC 8 Unique RAC Used for handoff Identifier informationretrieval

In a typical method according to the invention, the RAC 522 forwards theAttach Request to the HLR 523, all communications using the MAP protocolover an SS7 network. The HLR 523 either rejects the request with anAttach Reject 516 a, if, for instance the customer has not paid theirbill or the customer's cellular operator does not have a roamingagreement with this network operator; or asks the SIM card toauthenticate itself by sending an Authentication Request packet 516including the Kc, a key generated by secret parameters known only to theHLR and the SIM card, using A8 type GSM authentication protocols and oneor more RANDs, a random number of 64 bits, and the Signed Response(SRES) that can be authenticated using A5 type authentication protocols,which proves that the HLR knows the secret shared with the SIM card andis used to provide authentication of the SIM card to the operator'snetwork. The RAC 521 forwards the information in the AuthenticationRequest packet 516 using the Authentication Request packet 503 of the RRprotocol between the RAC and the RLM with the payload described in Table3, typically over the Internet protocol. TABLE 3 Field name Size inbytes Values Description RAND_Len 1 1 to 16 Length of RAND field inbytes RAND RAND_Len Random number Nonce Generated by the HLR SRES_Len 11 to 4 Length of SRES field in bytes SRES SRES Signed response usingGenerated by the Len_(—) the A3 GSM HLR algorithm of the Kc_Len 1 1 to 8Length of Kc field in bytes Kc Kc Len Key generated using Generated bythe the A5 GSM HLR algorithm and the

Alternatively the RAC 521 forwards the information in the Attach Rejectpacket 516 a using the Authentication Reject packet 503 a of the RRprotocol, as described in Tables 4 and 5, typically over the internetprotocol to the RLM 521. TABLE 4 Field name Size in bytes ValuesDescription Reject Code 1 Reject Reasons Shown in Table 5

TABLE 5 REJECT REASONS Code IMSI unknown in HLR 0x02 Illegal SubscriberIdentifier 0x03 GPRS services not allowed 0x07 Subscriber identitycannot be determined 0x09 Implicitly Detached OxOA

Table 5 shows reasons for rejecting the Attach Request and field valueto place in Attach Reject packet's Reject-Code field. If the RLMreceives the Authentication Request 503 it forwards the PPP LCP Acceptmessage 504 to the UE 520 that allows the PPP client to continue itsstate machine and respond to authentication requests. If the RLM 521receives the Authentication Reject message 503a it forwards the PPP LCPReject message 504a to the UE 520 that then terminates the PPPnegotiation.

After sending the PPP LCP Accept 504 message to the UE 520, the PPPstate machine at the RLM 521 initiates a CHAP session by sending achallenge packet 505 in the preferred embodiment using the LCPconfiguration option type 3, authentication protocol value 0×c223 forCHAP. For the Algorithm field we use the value 0×88 for SIM-basedauthentication to designate our algorithm as described below. During theCHAP exchange the Challenge field data sent to the UE 520 in packet 505from the RLM 521 consists of two 16 byte random numbers and the MACRAND, which is a signed version of the two random numbers combined withthe nonce, the two Kcs, the IMSI, and the two SRESs using the shah-1algorithm, a hash algorithm. Other hash algorithms, such as MD-5 mayalso be used. A Kc can be generated by the MLC on the UE 520 from eachRAND sent in message 503 to the RLM 521 and forwarded to the UE 520 inthe CHAP challenge message 505 by sending each RAND to the SIM card 417and getting a Kc as the response generated by the GSM algorithm A8.Using these generated keys, Kc, the UE 520 can then verify that theinformation in message 505 was signed correctly; if this is successful,it proves to the UE 520 that the RLM 521 was able to talk to the HLR 523and knows the Kc, thus authenticating the

RLM 521 is a legitimate interworking box for the customer's operator.The MLC in the UE 520 responds with the CHAP response message 506 thatincludes the MAC_SRES, which is a signed version of the two SRESs, thetwo Kcs, the nonce, and the IMSI sent to the RLM 521 in message 503using the shah-1 algorithm. The UE 520 generates each SRES from the RANDsent to it in message 505 that was forwarded from the value in the RANDfield of the Authentication Request packet 503 at the same time itgenerated the Kcs from the SIM card 417. When the RLM 521 receives theMAC SRES it verifies that the MAC SRES was signed correctly by the UE520 thus verifying that the UE 520 has the correct SIM card 417, thusauthenticating the customer's UE 520 to the RLM 521 or proving that theUE 520 could not authenticate itself by noticing the MAC_SRES was notsigned correctly. The RLM 521 then forwards this authentication fact tothe RAC 522 with an Authentication Response packet 507, the payload ofwhich is shown in Table 6. TABLE 6 Field name Size in bytes ValuesDescription Auth_Response 1 0x00 or 0x01 Success or Failure respectively

The RAC 522 then responds to the RLM 521 with an Attach Accept message508 indicating it understood the authentication fact. Assuming asuccessful authentication, the RLM 521 sends a PDP Context Activationmessage 509 to the GGSN 524 over the GTP control protocol to inform theGGSN that a GTP tunnel should be set up for the UE 520 allowing the UE520 to attach to the packet data network. The RLM 521 then sends a CHAPSuccess message 510 to the UE 520 to verify that the authentication wasdone correctly or a CHAP Failure message 510 a if authentication was notsuccessful. The RLM 521 then sends an Attach Complete message 511 to theRAC 522 so that it can complete its state machine and store theparameters of the UE 520 attach to be used for handover in the future.When the GGSN 524 is finished activating the GTP tunnel it sends a PDPContext Response message 512 to the RLM 521 which then sends the IPassignment information in message 513 to the UE 520, including theinformation necessary for the UE 520 to send IP packets to the PDN 306.The RLM 521 forwards notification of the GTP tunnel's successfulcreation to the RAC 522 in order to allow the RAC 522 to update itsstate machine and store the parameters of the UE 520's tunnel to be usedfor handover in the future.

Table 7 describes the payload of the attach accept packet. TABLE 7 Fieldname Size in bytes Values Description RAC 8 RAC ID Unique of serving RACAuth_Response 1 OxOO or Ox01 Success or Failure respectively

Table 8 is a payload description of the attach complete packet 511.TABLE 8 Field name Size in bytes Values Description Auth Response 1 OxOOor OxO1 Success or Failure respectively

The UE 520 has by this procedure now been successfully authenticated bythe GSM/GPRS core network and has a pair of tunnels set up for it, thefirst, using PPPOE, is between the MLC on the UE 520 and the RLM 521;the second, using GTP, is between the RLM 521 and the GGSN 524. ThePPPOE tunnel uses default encryption based on AES with the unique sharedkeys based on Kc, the nonce, and the IMSI which guarantees that packetssent by the UE 520 cannot be spoofed by anyone else on any network andthat the packets are private and cannot be snooped by anyone else on thepath from the UE 520 to the RLM 521. The RLM 521 takes the IP packetsreceived from the UE 520 on the PPPOE tunnel that are successfullydecoded and places them in the GTP tunnel to the GGSN 524. The GGSN 524takes those packets and sends them to the PDN 306. Data packetsaddressed to the UE 520 are received by the GGSN 524 who, for connectingto the packet data network of the Internet, advertises a public route tothe IP address assigned to the UE 520. The GGSN 524 places those packetsin the GTP tunnel and sends them to the RLM 521. The RLM 521 takes thosepackets, encrypts them and forwards them to the UE 520 over the PPPOEtunnel. The MLC on the UE 520 takes the received packets over the PPPOEtunnel, and after successfully decrypting them, passes them up the stackto other processes on the UE 520, thus providing a packet data networkconnection, typically an internet connection, to the UE 520. In thismanner, the preferred embodiment of the invention provides for secure,authenticated access to packet data networks through an operator'sunmodified core GSM/GPRS network for a UE 520 that only has a WLAN radio416 and SIM card reader 416 and SIM card 417.

The invention has been explained with reference to specific embodiments.Other embodiments will be evident to those of ordinary skill in the art.It is therefore not intended that the invention be limited, except asindicated by the appended claims.

1. A method for authenticating a WLAN radio user device in a wirelesslocal area network radio access network (WLAN RAN) using a core networksupporting GSM protocols comprising: connecting a Radio AccessController (RAC), a Radio Link Manager (RLM), and a WLAN Access Point(WLAN AP) to a Home Location Register (HLR) of a said core network;establishing communication of the WLAN radio user device with WLAN APand the RLM; authenticating the user device having Multilink Client(MLC) capabilities to the HLR; and thereafter attaching the user deviceto the core network system by: connecting a first datalink tunnel fromthe MLC to the RLM.
 2. The method according to claim 1 wherein saidauthenticating step further includes thereafter connecting a seconddatalink tunnel from the RLM to the GGSN packet gateway for a globalpacket data network.
 3. The method according to claim 1 wherein saidauthenticating step further includes thereafter connecting a seconddatalink tunnel from the RLM to an Internet gateway with tunnelingcapabilities and address assignment capabilities as part of a globalpacket data network.
 4. The method according to claim 3 wherein theInternet gateway employs Layer 2 Transport Protocol.
 5. A method forinterconnecting a wireless local area network radio access network (WLANRAN) to a GSM core network supporting GPRS packet protocols comprising:connecting a Radio Access Controller (RAC), a Radio Link Manager (RLM),and a WLAN Access Point (WLAN AP) to a GPRS Gateway Serving Node (GGSN)and a Home Location Register (HLR) of a said core network; establishingcommunication of a WLAN radio user device with the WLAN AP;authenticating the user device having Multilink Client (MLC)capabilities to the HLR; and thereafter attaching the user device to thecore network system by: connecting a first datalink tunnel from the MLCto the RLM.
 6. The method according to claim 5 wherein saidauthenticating step further includes thereafter connecting a seconddatalink tunnel from the RLM to the GGSN packet gateway for a globalpacket data network.
 7. The method according to claim 5 wherein saidauthenticating step further includes thereafter connecting a seconddatalink tunnel from the RLM to an Internet gateway with tunnelingcapabilities and address assignment capabilities as part of a globalpacket data network.
 8. The method according to claim 7 wherein theInternet gateway employs Layer 2 Transport Protocol.
 9. A method formutually authenticating a user device and a GSM core network via awireless local area network radio access network (WLAN RAN), the GSMcore network supporting GPRS packet protocols, said method comprising:initiating a wireless attach request from the user device; transmittingfrom the user device an identification number (IMSI) and a fresh randomnumber associated with the user (notice) via a wireless link to a radiolink manager; thereafter forming a conventional attach request using theIMSI and the nonce; thereafter conveying the conventional attach requestto a home location register; generating at the home location register aconventional authentication request using a 1) shared key of the userdevice, 2) the imsi and 3) the nonce, the conventional authenticationrequest including as an element a conventional digital signature;thereafter conveying the conventional authentication request to theradio link manager; thereafter forming at the radio link manager a firstsecure digital signature of said conventional authentication requestusing the nonce and all elements of the conventional authenticationrequest; thereafter conveying the first secure digital signature and amodified conventional authentication request having removed therefromsaid conventional digital signature to the user device; constructing atthe user device a candidate duplicate of the conventional digitalsignature from the modified conventional authentication request usingthe shared key, IMSI and nonce; verifying the candidate duplicate andthe modified conventional authentication request at the user deviceusing 1) the first secure digital signature, 2) the candidate duplicateand 3) the modified conventional authentication request to authenticatethe radio link manager to the user device; thereafter constructing atthe user device a second secure digital signature from the verifiedduplicate of the conventional digital signature using the shared keyed,IMSI, and the nonce and the verified modified conventionalauthentication request; and thereafter reporting the second securedigital signature to the radio link manager to verify authentication ofthe user device to the radio link manager.
 10. The method according toclaim 1 wherein said authenticating step comprises: initiating awireless attach request from the user device; transmitting from the userdevice an identification number (IMSI) and a fresh random numberassociated with the user (nonce) via a wireless link to a radio linkmanager; thereafter forming a conventional attach request; thereafterconveying the conventional attach request to a home location registerusing the IMSI and the nonce; generating at the home location register aconventional authentication request using a 1) shared key of the userdevice, 2) the imsi and 3) the nonce, the conventional authenticationrequest including as an element a conventional digital signature;thereafter conveying the conventional authentication request to theradio link manager; thereafter forming at the radio link manager a firstsecure digital signature of said conventional authentication requestusing the nonce and all elements of the conventional authenticationrequest; thereafter conveying the first secure digital signature and amodified conventional authentication request having removed therefromsaid conventional digital signature to the user device; constructing atthe user device a candidate duplicate of the conventional digitalsignature from the modified conventional authentication request usingthe shared key, IMSI, and nonce; verifying the candidate duplicate andthe modified conventional authentication request at the user deviceusing 1) the first secure digital signature, 2) the candidate duplicateand 3) the modified conventional authentication request to authenticatethe radio link manager to the user device; thereafter constructing atthe user device a second secure digital signature from the verifiedduplicate of the conventional digital signature using the shared keyedand the verified modified conventional authentication request; andthereafter reporting the second secure digital signature to the radiolink manager to verify authentication of the user device to the radiolink manager.
 11. The method according to claim 1 further including thestep of using a shared key shared between the user device and the HLR toestablish said first datalink tunnel as a secure datalink tunnel.
 12. Asystem for interconnecting a wireless local area network radio accessnetwork (WLAN RAN) to a GSM core network supporting GPRS packetprotocols comprising: a Radio Access Controller (RAC); a Radio LinkManager (RLM); a WLAN Access Point (WLAN AP); a GPRS Gateway ServingNode (GGSN); a Home Location Register (HLR) of a said core network; atleast one WLAN radio user device for communication with the WLAN AP;means for authenticating the user device to the HLR, said user devicehaving Multilink Client (MLC) capabilities; and means for attaching theuser device to the core network system using a first datalink tunnelfrom the MLC to the RLM and a second datalink tunnel from the RLM to theGGSN packet gateway for a global packet data network.
 13. A system forinterconnecting a wireless local area network radio access network (WLANRAN) to a GSM core network comprising: a Radio Access Controller (RAC);a Radio Link Manager (RLM); A WLAN Access Point (WLAN AP); an InternetGateway Node; a Home Location Register (HLR) of a said core network; atleast one WLAN radio user device for communication with the WLAN AP;means for authenticating the user device to the HLR, said user devicehaving Multilink Client (MLC) capabilities; and means for attaching theuser device to the core network system using a first datalink tunnelfrom the MLC to the RLM and a second datalink tunnel from the RLM to theInternet Gateway Node for a global packet data network.